Trusted Computing Group (TCG) use cases provide the means for remote parties to attest to the software state of a computer system/platform. The software state includes measurements of the software chain and might include configuration files used to initialize or customize a software module. The attestation method, according to the TCG, implements a transitive trust chain architecture where each layer of software measures the next layer before executing it. The procedure begins with the Core Root of Trust for Measurement (CRTM) that measures parts of the firmware of the machine (BIOS on a PC) before it starts executing it. Subsequently, each layer in turn measures the next-to-be-executed layer before calling it. Digests of these measurements are accumulated through a one-way hash function, also known as a extend operation, into Platform Configuration Registers (PCRs) contained in the Trusted Platform Module (TPM). The names of measured pieces of software and their measurement values are appended to a measurement log.
During the remote attestation process, a set of PCRs is quoted, digested, and digitally signed with a trusted Attestation Identity Key (AIK) held inside the TPM. The remote party/system receives the quote, public AIK key and the certificate of the AIK and validates the AIK certificate, which has previously been issued by a trusted privacy certificate authority. The remote party/system also verifies the digital signature of the quote and the integrity of the list of measurements by comparing it to the PCR state included in the quote. Once the list of measurements is found to be trusted, the remote system uses it to determine whether the attested system is running trusted software.
Currently, with a non-virtualized platform, a system's single TPM holds the result of all individual measurements in its PCR registers. The platform also maintains a list of measurements in main memory. Furthermore, the platform runs an attestation service process for remote parties/systems to connect to and request the reporting of measurements.
Similarly, in a virtualized environment, each virtual machine (VM) has a corresponding TPM. To attest to a VM, the remote party must know how to connect to it, and the VM must be running an attestation service process.
Further, each VM's TPM contains common early measurements such as those of the firmware (BIOS on a PC), master boot record, and the virtual machine monitor (VMM) following the aforementioned TCG transitive trust architecture. A remote party attesting to more than one VM may receive duplicate measurements if the VMs all run the same software.
In addition, a remote party only receives measurements reflecting a single point in time. Therefore, the remote party must continuously poll each VM if it wants to detect new entries in the measurement log.
These attributes limit attestation in cases where a VM is not aware of the attestation process or where the remote party cannot locate the server. Further, they do not scale well in cases where a platform hosts many VMs or where a remote party wants to continuously monitor the state of the software inside multiple VMs.
A data center typically hosts many virtualized platforms where on each platform many VM's may be running simultaneously. For trust establishment purposes, each one of the operating systems that is running inside a VM may have been instrumented to take measurements of executables that are started and libraries that link against these applications or driver modules that are loaded into the kernel. Each of the measurements is accumulated in platform configuration registers (PCRs) of a virtual TPM instance associated with a VM.